Method and device for graphical interfacing

ABSTRACT

A method and device for graphical interfacing between a user and an information system. The method includes introducing a user request in a client station, transmitting the request to a server, processing the request and generating an answer and transmitting the answer to the client station. The generated answer includes instruction data and displayable data, instruction data determining a useable visualization model is interpreted in the client station, the visualization model is formed in the client station by associating locally available construction elements and the displayable data together with the visualization model are merged in order to display a merging result. The method is used for producing a graphical user interface.

The present invention relates to a method and a device for a graphicuser interface with a computer system.

It more specifically applies to carry out graphical user interfacesnotably in the field of computerized reservation systems.

User interfaces have, in general, much evolved with the adoption anddramatic spread of wide area networks and, particularly, the Internet.

Within the framework of Internet, graphical interface solutions haveallowed important savings as far as products development is concerned.

However, for sophisticated applications such as business applicationsthat deal with computerized reservation systems, user interfaces basedon these techniques require to have to transfer large bulky pagesformatted according to a markup language such as HTML (Hyper TextMark-up Language).

Drawbacks are related to this type of transmission in which onlyintegral pages, built in the server part, are transmitted to thenavigator of the client terminal. This poses several problems. Inparticular, the client part of the user interface exhibits significantstructural limitations due to the HTML language. Moreover, taking intoaccount the size of the transfers to be performed between the server andthe client terminal, the occupation of the transmission network is high,which implies a higher response time for the clients equipped with alow-speed connection.

This way of building HTML pages appears in document US-A-2002116455.

According to slightly different techniques, “style sheets” are locallystored to be re-used and merged with dynamic files. However, these stylesheets are predetermined and their characteristics set once for all.They do not offer any flexibility while they are used. For example, ifone has to create a page with a style sheet that hardly differ from astyle sheet present in the local cache the local sheet is not howeveruseable and it is necessary to obtain a new complete style sheet fromthe server.

There is a need regarding user interfaces possessing the properties ofrichness, flexibility and performance as processed in the server partwhile ensuring a reduction of the network occupation when provided fordisplay to the client.

The present invention falls within the scope of this tradeoff and allowsreducing, on the one hand, the computing time on the server and, on theother hand, the traffic on the network between the server and theclient, which makes it possible to decrease the total response time ofthe application. Moreover, the device of the invention maintains a greatdeal of flexibility because the server part keeps controlling theprocessing of data to be displayed. The device also makes it possible tomodify and create for the user the graphic visualization models to bedisplayed along with the delivery of instructions regarding the clientterminal display.

More precisely, the invention has the advantage of providing to thedisplay means information merged from two data sources. Indeed, on theone hand, the device of the invention generates static objects, heldlocally at the level of the client terminal and allowing a localavailability of multiple graphic objects used for display.

On the other hand, the dynamic data corresponding to the client requestare generated after processing in the server part and are transmitted tothe client terminal. Merging of the dynamic and static data is thenperformed to produce visualization especially, under the form offormatted HTML pages through the use of a navigator.

By implementing specific equipment to the level of the client terminal,one can generate locally the model of visualization to be used fordisplay. That is obtained from the association of various modelconstruction elements which will be further detailed in the description.

It follows that the construction data of the visualization models arenot forwarded any more through the network. Moreover, the system iseasily personalized according to the local requirements of the clientterminal (specific graphic objects, particular logical rules to apply,particular local data to use . . . ).

This potential personalization of the client terminal does not affectits original components and in particular the navigator: one can indeedgenerate a formatted HTML page with the navigator. It will be also notedthat the visualization models being created from low size objects,updating them requires only few network resources.

The volume of data to be transmitted is thus reduced significantlybetween the server part and the client terminal. Therefore, one takesadvantage of the richness of standard markup languages, such as HTML,while decreasing considerably the response time and the networkrequirements.

Other objects and advantages will become apparent in the descriptionwhich follows of a preferred embodiment of the invention which ishowever not restrictive.

The present invention relates to a method for a graphic user interfacewith a computer system in which following operations are performed:

-   -   User inputs a request from a client terminal,    -   Request is transmitted to a server part for the purpose of being        processed and to generate a response,    -   Client terminal receives the response,    -   Result of response is displayed for the user,

According to the invention:

-   -   The client terminal receives a response which is comprised of        instruction data and of data to be displayed;    -   At the level of the client terminal, instruction data are        executed in order to construct a visualization model to be used    -   At the level of the client terminal, the above visualization        model is created through the association of construction        elements locally available;    -   Data to be displayed are merged with the visualization model in        order to display merging result.

According to advantageous but nonrestrictive possibilities:

-   -   The construction elements include a descriptive interface of the        visualization model objects, a presentation layer and some        logical rules to be applied locally to the visualization model;    -   At the level of the client terminal, among the language        resources locally available, one is associated to the created        visualization model;    -   At the level of the client terminal, one may associate to the        visualization model some personalization display filters in        order to modify the visual rendering of the default        visualization model;    -   The instruction data include the indication of the type and        characteristics of the construction elements for the        visualization model to be created;    -   Locally available data are updated at the level of the client        terminal through the following steps:    -   At the level of the server, a storing message is generated which        includes storing instruction data and data to be stored,    -   Storing message is transmitted to the client terminal,    -   At the level of the client terminal, instruction data are        interpreted in order to perform the storing and the message data        to be stored are stored in a local memory,    -   Display is performed at the level of the client terminal through        the use of a navigator,    -   Some of the data to be displayed and some construction elements        of the visualization model use a XML format;    -   Merging result is translated to the HTML format in order to be        displayed,    -   Response from server part is comprised of instruction data and        data to be displayed.

The invention also relates to a graphical interface device between auser and a computer system comprising:

-   -   Means for inputting a user request at the level of the client        terminal,    -   Means for communicating between the client terminal and a server        part,    -   Processing means for generating a response from the server part,    -   Means for displaying the result of the response at the level of        the client terminal.    -   It includes, at the level of the client terminal, an        instructions manager capable of interpreting instruction data        for the construction of a visualization model framework;    -   It includes, at the level of the client terminal, an association        engine capable of creating the above visualization model from        the association of construction elements;    -   It includes, at the level of the client terminal, storing means        for the construction elements;    -   It includes, at the level of the client terminal, means for        merging the visualization model with the data to be displayed in        order to display the merging result.

In a preferred embodiment:

-   -   The construction elements include a descriptive interface of the        visualization model objects, a presentation layer and some        logical rules to be applied locally to the visualization model;    -   It includes a rule engine capable of applying the logical rules        of the visualization model;    -   It includes a navigator to display the merging result at the        level of the client terminal.

The accompanying drawings illustrate, by way of examples, the inventionand are not meant to limit its scope. They represent only one embodimentof the invention in order to easily understand it.

FIG. 1 is a schematic representation of the process that presently takesplace between a client and a server when a user issues a request, usinga navigator such as Internet Explorer®, in an architecture based on theInternet system.

FIG. 2 schematically shows the process of a user request when inventionis carried out.

FIG. 3 is a bloc diagram of a device according to the invention andillustrating their interactions.

FIG. 4 shows the merging step of the data.

FIG. 5 is an example of component integrated in the visualization meansof the client terminal.

FIG. 1 describes a standard scenario while using the world networkusually referred to as the “World Wide Web”. In this case, the userrequests at the level of client part consist in requesting HTML (HyperText Mark-up Language) formatted pages with the following instructions:http get or http post.

A first limitation of this mechanism is that user must specify thewindow in which display will occur and this, before sending the request.The server is thus not free to decide to display the response in adialog window or in the main window since this has been defined at theclient level.

Another drawback that can be raised is that only one window can berefreshed at a time. For example, if the main window had been divided intwo sub-windows user needs to forward two successive requests to theserver to get the two sub-windows successively refreshed. Also, thedisplay modifications can only occur through a complete refreshing of anintegral screen part even though it is possible that the user requestconsists in a simple updating of certain displayed data. According tothe present device it is however necessary to refresh the whole screenfor any type of requested modifications.

There is no means of efficiently storing information at the level of theclient terminal unless to use “cookies” which are however of small sizeand require a transit through the network with each request.

Once user has entered his/her request it is transmitted through theInternet network using communication protocols like HTTP (Hyper TextTransfer Protocol). This step is shown in FIG. 1 at reference mark 1.The process of the request is performed at the level of the server andshown at reference mark 2. A response is then generated as shown atreference mark 3, here under the form of a HTML formatted page, whichimplies to combine in a same response the data elements and thepresentation elements of what is to be displayed for the user. Hence,each time one wishes to access a page it is necessary to download, fromthe server part, the totality of the HTML page including the data to bedisplayed (variable data and formatting ‘static’ data e.g.: help texts,colors, fonts. Thus, the traffic generated on the network to transmitpages is large.

Reference mark 4 in FIG. 1 shows that response, which takes the form ofa HTML page, is forwarded to the client. It is worth noting that, forbusiness applications, data must be encrypted which implies a processtime all the more significant as the size of data to be encrypted ishigh.

At the level of the client terminal, display of the response is madeavailable to the user as shown at reference mark 5 in FIG. 1. Display iscarried out through the use of a navigator such as the one known underthe brand name of Internet Explorer®.

Some operations may be carried out locally to prevent from having tosystematically access the server. Thus, some applications e.g., thoseedited in JavaScript can be implemented to get certain tools. Anotherdrawback of the present devices is therefore that it becomes necessaryto have recourse to additional tools to be programmed in JavaScriptlanguage at the level of the client terminal.

On the contrary, FIG. 2 shows an exemplary scenario of a graphicalinterface device operating according to the invention.

As previously pointed out, the current architecture used for theInternet network (World Wide Web) raises problems dealing with the factthat the integrality of HTML pages are downloaded to the clientterminal.

As shown in FIG. 2 this is not the case of the present invention.

More specifically, as user request destined for the server part isinputted, a XML (Extensible Mark-up Language) or other structuredformatted message is issued that include information entered by theuser. As client request thus generated represents the user action it hasbeen named ‘event’ in FIG. 2 at reference mark 1.

After transmission this ‘event’ request is received and processed at thelevel of the server part. The first processing phase consists inanalyzing the request content, which is done by a user interface layerin the server and will be more detailed here after. Then, one proceedsto the process of the ‘event’ request data in an application layer thatwill be also further discussed here after.

These processing phases are shown in FIG. 2 at reference mark 2‘process’. Once request has been processed the server part generates theappropriate response towards the client. In this case, instead ofbuilding a complete formatted HTML page, according to the invention, aseries of instructions is rather generated to be interpreted by theclient. As far as the client terminal behavior is concerned this givesit a great deal of flexibility. For example, a single message may allowto perform refresh operations of a screen part, to open a dialog box, todisplay message etc. and this, in a simultaneous way.

Once created message is forwarded under the form of a XML (ExtensibleMark-up Language) document to the client terminal, possibly after havingbeen compressed and encrypted. This operation is depicted at referencemark 4 where it is designated by the term ‘instructions’ whichcorresponds to the functionality described in previous chapter.

This instructions message is received at the level of the clientterminal and must be interpreted.

Especially, the dynamic data included in the server response areextracted and could be merged with a visualization model whichcorresponds to the static objects necessary for the display. Eachvisualization model is moreover created at the level of the clientterminal through the association of construction elements. These are theinstruction data which determine what construction elements have to beassociated. The combination through a merge of two data types(presentation layer and dynamic data issued from the server) makespossible the creation of complete data to de displayed; especially,under the form of a HTML formatted page. It is then possible to use forthe visualization the functionalities of known standard navigation meanssuch as the navigator distributed under the brand name of InternetExplorer®.

Multiple advantages result from the merge operation thus carried out inthe client part. First, once visualization models and their dependingelements (images, scripts, etc. . . . to which models make reference)have been obtained, and are available at the level of the clientterminal, only dynamic elements have to be forwarded through thecommunication network. The requirements on the network are thus muchlowered.

The update of the static data is moreover very sparing in transmissionresources because the concerned elements are of small sizes. Forexample, if a graphical object must be changed it is not necessary todownload the whole visualization model that uses it.

Moreover, only the data transmission channel needs to be secured in thecommunication means which allows limiting the capacity of the requiredencrypting means when secure communications have to be considered.

Once the merge has been performed its result can be displayed at thelevel of the client terminal such as shown at step 5 of FIG. 2.

A local interaction with the user is then possible as shown at step 6and implements a rule engine able to apply logical rules associated tothe visualization model used and available locally as this is furtherexplained here after. It may include different modes of operation.

Especially, if the instructions transmitted by the server correspond tosome controls (such as a box to display a drop-down list) the events tooperate it can be managed by a JavaScript formatted code associated tothe control considered.

If the operational events comprise interactions between differentcontrols (for example, if field A was filled in then, field B becomesmandatory) this can be achieved of different manners.

Thus, if the interaction is complex, but seldom used, it can be managedat the level of the server and asked under the form of a request issuedby the client terminal to the server.

If the interaction is simple, and can be easily implemented, it ismanaged at the level of the client terminal by the local rule engine.

Finally, if none of the above options appear to be convenient it ispossible to implement some formatted JavaScript short coding elements tobe linked to the page to achieve functionalities such as those currentlyknown in the field of HTML pages used for the World Wide Web.

A possible structure for a device according to the invention is moreaccurately described here after. Device comprises a server partimplemented from known computer means including processing means underthe form of processors and storing means under the form of memories likeRAM (Random Access Memory) and ROM (Read Only Memory). The server partcan be remotely made of a single entity or can be a cluster ofindividual servers connected together through usual transmission means.

The device is also comprised of a locally implemented part at the levelof the client terminal that can be performed, for example, by a PC(Personal Computer) as shown in FIG. 3.

The server part and the client terminal are connected, for datatransmission, through communication means belonging to a network (N)which is, for example, a WAN or Wide Area Network.

In FIG. 3 different device components are depicted along with theirinterrelations in order to carry out the interfacing method heredescribed.

Through the use of the network N, the server part transmits a responseto the request previously issued par the user; response comprises someinstruction data and some data to be displayed.

In particular, the XML standard could be used as markup formattedlanguage. The response is received by an instruction manager able tointerpret the instruction data contained in the response in order todetermine what operations have to be carried out. In the case where adisplay is to be done, the interpretation includes determining theconstruction elements to be used for the generation of the visualizationmodel.

The interpretation results are forwarded to an association engine ableto extract the static data constituting the construction elementscomponents that characterize the model of visualization previouslydetermined. In FIG. 3 different construction elements used for creatingthe visualization model are depicted In particular, the visualizationmodel associates an interface aimed at describing its high levelcomponents, a presentation layer including the different elements andattributes related to a graphic presentation and some logical rules tobe applied to the visualization model while it is processed.

In a preferred embodiment the presentation layer can be made dependentof user profiles however the description interface and the logical rulesremain identical. As a consequence, the construction elements can betotally independent data thus can be either stored in separated files orin a same file according to the needs

Moreover, other elements are advantageously associated to thevisualization models thus created. Especially, language resource dataare associated. These data are also chosen among different resourceslocally available in cache memory at the level of the client terminal.It is then easy to adapt the page to be created to a predeterminedlanguage. The indication de language resource to use is also present inthe instruction data received in the response.

To the visualization model, one or several filters can also beassociated. These filters complement the personalization made possibleby the present invention. Indeed, they allow adapting the availableinformation to be displayed to some specific client parameters. It is anespecially efficient means to modify the screen visual components in anon-programmatic way such as the user controls (e.g.: deletion of somescreen controls, modification regarding the mandatory filling of someinput fields . . . ).

Finally, the association of the visualization model to one or morefilters, to language resources and to dynamic data received in theresponse makes possible the formation of a page.

This association is more particularly shown in FIG. 5.

Coming back to FIG. 3 it is shown that the merge between the static datathus associated and the dynamic data contained in the response isperformed by a merging means. By means of merge it is possible e.g., tocreate XML formatted data.

The standard navigators and especially, Internet Explorer®, operate withHTML formatted pages. Hence, before transmission to the navigator atransformation into a HTML format is performed with the help oftransforming means.

The steps ending up with the display to the user are those currentlyimplemented in existing navigators. However, to allow improvedinteractions with user, without having to systematically involve theserver part, the device according to the invention also comprises arules engine able to operate from rules contained in a data store. Inthis way, simple interactions between the navigator and the user can bemanaged. For example, it is possible to locally determine what data haveto be displayed in a drop-down menu according to the client profile anddepending on what was the previous input made by the user. This preventsfrom having to systematically access the server after each client input.

It is also shown in FIG. 3 an opportunity to update or add data in thedata store. Indeed, it can be useful to refresh or to supplement thedata contained locally in the data store and used by the rules engine.To this end, from the server part, a response is forwarded to the clientterminal which contains instruction data and operational data in view oftheir storing and not for the purpose of being displayed.

When the storing instruction is received it is interpreted. Thistriggers a storing operation, into the data store, of the data containedin the response.

This step is also shown in FIG. 3.

Also, the client terminal advantageously comprises a cache elementserving as a storing means for the locally available data within which aplurality of data can be stored including the different constructionelements. These are static data generally used by pages of the HTMLtype. Any type of memory can be used for such a cache memory especially,a ROM or Read-Only-Memory.

According to a first possibility, the static data are installed from thebeginning in the client terminal and are used when requested to bemerged with the data issued from the server. Hence, server does not haveto transmit the different elements and objects used for the display.

It may also happen that some elements necessary for the display howevernot initially present must be used.

In this case the present invention allows the creation of theconstruction elements in the server part and their transmission, oncefor all, to the client terminal in order to be stored in the cache sothat they become re-usable.

In FIG. 4 the merging step is shown between the data issued from theserver and the data coming from the cache after they have beenassociated.

In this case, it is shown that the merge is performed in the clientterminal part after reception of the dynamic data issued from the serverwithin the instructions constituting the server response. Theinstructions manager, upon reception of the data server, calls thecorresponding elements of the visualization model present in the cache.They are associated and merged, for example, to build a page to betransmitted to the display means.

If a necessary construction element is not initially present in thecache, the operation previously described, regarding its transmissionfrom the server part to the client terminal, is first carried out

XML formatted data are advantageously processed for the creation of thevisualization model and for the data to display. A translation to theHTML format can be performed by the transforming means, after the mergehas occurred, in order to obtain a result under the form of a HTML pagewhich can be directly handled by current navigators.

It is worth noting that the objective of the present invention enables agreat deal of flexibility in the development of graphic user interfaceswhile limiting the quantities of transmitted data across networks. Alsothe client terminal remains a light structure that can be easily set upwhile the server part keeps playing a chief role in the process of thedata and in the management of the visualization elements.

1-12. (canceled)
 13. Method for graphic interfacing between a user and acomputer system in which the following operations are performed:inputting a user request at the level of client terminal, transmittingthe request to a server part in view of being processed and forgenerating a response, receiving the response at the level of the clientterminal, displaying the response result for the user, wherein: theclient terminal receives a response comprising instruction data and datato be displayed; at the level of the client terminal, instruction dataare executed in order to construct a visualization model to be used; atthe level of the client terminal, said visualization model is createdthrough the association of construction elements locally available; datato be displayed are merged with the visualization model in order todisplay merging result.
 14. Method according to claim 13, wherein theconstruction elements include a descriptive interface of thevisualization model objects, a presentation layer and some logical rulesto be applied locally to the visualization model.
 15. Method accordingto the claim 13, wherein at the level of the client terminal, among thelanguage resources locally available or downloadable from the serverpart, one is associated to the created visualization model.
 16. Methodaccording to claim 13, wherein at the level of the client terminal, somepersonalization display filters are associated to the visualizationmodel in order to modify the visual rendering of the defaultvisualization model.
 17. Method according to claim 13, wherein theinstruction data include the indication of the type of constructionelements characterizing the visualization model to be created. 18.Method according to claim 13, wherein locally available data are updatedat the level of the client terminal through the following steps: at thelevel of the server, a storing message is generated which includesstoring instruction data and data to be stored, storing message istransmitted to the client terminal, at the level of the client terminal,instruction data are interpreted in order to perform the storing, andthe data to be stored are stored in a local memory.
 19. Method accordingto claim 13, wherein display is performed at the level of the clientterminal through the use of a navigator.
 20. Method according to claim13, wherein some of the data to be displayed and some constructionelements of the visualization models use a XML format; merging result istranslated to the HTML format in order to be displayed.
 21. Graphicinterface device between a user and a computer system, comprising: meansfor inputting a user request at the level of the client terminal, meansfor communicating between the client terminal and a server part,processing means for generating a response from the server part, meansfor displaying the result of the response at the level of the clientterminal, wherein the response from the server part comprisesinstruction data and data to be displayed; said device furthercomprising: at the level of the client terminal, an instructions managerable to interpret the instruction data in order to construct avisualization model to be used; said device further comprising: at thelevel of the client terminal, an association engine able to create saidvisualization model through the association of construction elements;said device further comprising: at the level of the client terminal,storing means for the construction elements; said device furthercomprising: at the level of the client terminal, means for merging thevisualization model and the data to be displayed in order to display themerging result.
 22. Device according to claim 21, wherein theconstruction elements include a descriptive interface of thevisualization model objects, a presentation layer and some logical rulesto be applied locally to the visualization model.
 23. Device accordingto claim 22, further comprising a rules engine able to apply the logicalrules of the visualization model.
 24. Device according to claim 21,further comprising at the level of the client terminal, a navigator todisplay the merging result.